Protocol conversion device and method

ABSTRACT

An IWF device ( 3 ) is divided into an IWF-c ( 31 ) as a C plane device controlling signaling and an IWF-u ( 32, 33 ) as a U Plane device controlling user data. Thus, it is possible to constitute configuration having flexible scalability.

TECHNICAL FIELD

The present invention relates to a protocol conversion device and methodand, more particularly, to a protocol conversion device and method whichare applied when devices using different physical lines are connected.

BACKGROUND ART

The protocol architecture of a radio interface in a WCDMA (WidebandCDMA) system includes a physical layer (layer 1), data link layer (layer2), and network layer (layer 3). Layer 2 has a C-Plane for signalling oftransferring a control signal, and a U-Plane for transferring userinformation.

In connecting devices using different physical lines, an IWF (InterWorking Function) device is applied as a protocol conversion device. Theconfiguration of a conventional IWF device is not divided into theC-Plane and U-Plane (see, e.g., reference 1 (3GPP TR25.933 V5.2.0(2002-09)).

For this reason, if the configuration is actually divided into theC-Plane and U-Plane, a problem occurs in the resource reservation methodof how to terminate each protocol and how to acquire a parameter forreserving a resource. This inhibits the use of a configuration with highscalability for increasing/decreasing the U-Plane. No resourcereservation is described in reference 1.

DISCLOSURE OF INVENTION

The present invention has been made to overcome the conventionaldrawbacks, and has as its object to provide a protocol conversion deviceand method which can adopt a configuration with high scalability.

To achieve the above object, according to the present invention, aprotocol conversion device which is connected between a first device anda second device that use different physical lines is characterized bycomprising a C-Plane device which controls signalling between the firstdevice and the second device, and a U-Plane device which controlstransfer of user data between the first device and the second device.

Also, according to the present invention, a protocol conversion methodapplied when a first device and a second device that use differentphysical lines are connected is characterized by comprising the firststep of controlling signalling between the first device and the seconddevice by a C-Plane device, and the second step of controlling transferof user data between the first device and the second device by a U-Planedevice which is arranged independently of the C-Plane device.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram showing the configuration of an IWF deviceaccording to the first embodiment;

FIG. 2 is a block diagram showing the configurations of an IWF-c andIWF-u in FIG. 1;

FIG. 3 is a view showing the protocol stack of the C-Plane according tothe first embodiment;

FIG. 4 is a sequence chart showing operation upon issuing a CS callaccording to the first embodiment;

FIG. 5 is a sequence chart showing operation upon issuing a PS callaccording to the first embodiment;

FIG. 6 is a flowchart showing operation of the IWF-c in FIG. 1;

FIG. 7 is a flowchart showing operation of the IWF-c in FIG. 1;

FIG. 8 is a flowchart showing operation of the IWF-u in FIG. 1;

FIG. 9 is a flowchart showing operation of the IWF-u in FIG. 1;

FIG. 10 is a block diagram showing the configuration of an IWF deviceaccording to the second embodiment;

FIG. 11 is a block diagram showing the configurations of an IWF-c andIWF-u in FIG. 10;

FIG. 12 is a view showing the protocol stack of the C-Plane according tothe second embodiment;

FIG. 13 is a sequence chart showing operation upon issuing a CS callaccording to the second embodiment;

FIG. 14 is a sequence chart showing operation upon issuing a PS callaccording to the second embodiment; and

FIG. 15 is a flowchart showing operation of the IWF-u in FIG. 10.

BEST MODE FOR CARRYING OUT THE INVENTION

Embodiments of the present invention will be described below withreference to the accompanying drawings.

FIRST EMBODIMENT

FIG. 1 is a block diagram showing the configuration of an IWF (InterWorking Function) device as a protocol conversion device according tothe first embodiment of the present invention. In FIG. 1, an IWF device3 comprises an IWF-c 31 which mainly performs signalling control, andIWF-us 32 and 33 which mainly perform transfer of user data. The IWF-c31 corresponds to the C-Plane for signalling of transferring a controlsignal, whereas the IWF-us 32 and 33 correspond to the U-Plane fortransferring user information. Note that signalling means a process ofconnecting a line, and user information is a packet which flows througha line connected by signalling.

The IWF device 3 is connected between an MSC (Mobile Switching Center) 4or an SGSN [Serving GPRS (General Packet Radio Service) Support Node] 5serving as the first device, and an RNC (Radio Network Controller: basestation control device) 1 serving as the second device. The IWF device 3and the MSC 4 or SGSN 5 are connected by an ATM (Asynchronous TransferMode) Transport protocol stack which is defined by 3GPP (3rd GenerationPartnership Projects) Release 99. The IWF device 3 and RNC 1 areconnected by an IP (Internet Protocol) Transport protocol stack which isdefined by 3GPP Release 5. These protocol stacks are described as Iuinterfaces in detail in reference 2 (3GPP TS25.412 V5.1.0 (2002-09)) andthe like.

The IWF-c 31 of the IWF device 3 converts an ATM Transport protocolstack and IP Transport protocol stack in signalling. The IWF-us 32 and33 of the IWF device 3 convert an ATM Transport protocol stack and IPTransport protocol stack in user information transfer.

The RNC 1 comprises control signal transmission/reception sections(signalling control devices) 11 to 13 which transmit/receive a controlsignal, and data transmission/reception sections 21 to 23 whichtransmit/receive user information.

FIG. 2 is a block diagram showing the configurations of the IWF-c 31 andIWF-u 32 in FIG. 1.

In FIG. 2, the IWF-c 31 is formed from a resource management unit 311,protocol termination units 312 and 314, and an interface (I/F) unit 313with the IWF-u 32. The IWF-u 32 is formed from a switch control unit321, a switch 322, an interface (I/F) unit 323 with the IWF-c 31,protocol termination units 324 to 326 on the ATM side, and protocoltermination units 327 to 329 on the IP (Internet Protocol) side.

FIG. 3 is a view showing the protocol stack of the C-Plane according tothe first embodiment. In FIG. 3, the RNC 1 is made up of a Data linklayer, an IP layer, an SCTP (Stream Control Transmission Protocol)layer, an M3UA [SS7 (Signalling System No. 7) MTP3 (Message TransferPart 3) User Adaptation] layer, an SCCP (Signalling Connection ControlPart) layer, and an RANAP (Radio Access Network Application Part) layer.

The IWF-c 31 is formed on the side of the RNC 1 from a Data link layer,IP layer, SCTP layer, M3UA layer, SCCP layer, and RANAP layer, and onthe side of the MSC 4 and SGSN 5 from an ATM layer, an SAAL-NNI(Signalling ATM Adaptation Layer-Network Node Interface) layer, anMTP3-B (Message Transfer Part 3-B) layer, an SCCP layer, and an RANAPlayer.

Each of the MSC 4 and SGSN 5 is formed from an ATM layer, SAAL-NNIlayer, MTP3-B layer, SCCP layer, and RANAP layer.

In this case, one terminal of the SCCP layer is terminated by the IWFdevice 3. To the contrary, the RANAP layer as the uppermost signallingprotocol is terminated between the RNC 1 and the MSC 4 or SGSN 5 thoughpart of the RANAP layer must be determined. Some of messages change incontents about a resource address.

As a result of terminating one terminal of the SCCP layer by the IWFdevice 3, two SCCP connections are set for one call between the RNC 1and the IWF and between the IWF and the MSC 4 or SGSN 5. The SCCP layerhas, in the resource management unit 311 of the IWF device 3, an SCCPcorrespondence table for making the two SCCP connections correspond toeach other. Based on this table, the IWF device 3 terminates oneterminal of the SCCP, recognizes call information, and transmits thecall again to a proper destination. A proper transmission/receptionsection can, therefore, be selected from the control signaltransmission/reception sections 11 to 13 in the RNC 1.

Note that the CS (Circuit Switched) call has been described in detail,and the above description can also apply to a PS (Packet Switched) callusing the SGSN 5 instead of the MSC 4. The CS call is an audio line callusing the MSC 4, and the PS call is a packet communication call usingthe SGSN 5.

FIG. 4 is a sequence chart showing operation upon issuing a CS callaccording to the first embodiment. Operation up to reservation of theresource of each device upon issuing a CS call according to the firstembodiment will be explained with reference to FIG. 4.

When a UE (User Equipment) transmits “Connection Request” (a1 in FIG. 4)to the RNC 1, a calling sequence starts. When the RNC 1 transmits“Initial UE Message” to the MSC 4, SCCP connections are set between theRNC 1 and the IWF-c 31 and between the IWF-c 31 and the MSC 4 (a2 and a3in FIG. 4). At this time, the SCCP connection between the RNC 1 and theIWF-c 31 is defined as SCCP connection #1, and that between the IWF-c 31and the MSC 4 is defined as SCCP connection #2.

The IWF-c 31 only relays “Initial UE Message”, migrates the SCCP fromSCCP connection #1 to SCCP connection #2, and transmits the SCCP to theMSC 4 (a4 and a5 in FIG. 4). The resource management unit 311 of theIWF-c 31 creates an SCCP correspondence table representing that SCCPconnection #1 and SCCP connection #2 are used by the same call. When anSCCP connection is first set by the MSC 4 in Paging or the like, theIWF-c 31 has a function of arbitrarily selecting a control signaltransmission/reception section.

In a multi-call during the use of a call, the IWF-c 31 has a means fordetermining, on the basis of information (e.g., IMSI (InternationalMobile Subscriber Identity)) unique to a terminal, whether the terminalis in use, and allowing the use of the same control signaltransmission/reception section.

After authentication and concealment are performed (a6 in FIG. 4), theMSC 4 reserves a user data resource (a7 in FIG. 4), and transmits, tothe RNC 1, “RAB Assignment Request” (first resource request) to reservea radio resource (a8 in FIG. 4). Upon reception of this message, theIWF-c 31 determines that the resources of the IWF-us 32 and 33 must bereserved. A case wherein the resource of the IWF-u 32 is reserved willbe explained.

“RAB Assignment Request” contains the first parameter (e.g., address)used to transfer user data by the MSC 4. The resource management unit311 of the IWF-c 31 acquires the first parameter from “RAB AssignmentRequest”, adds the first parameter to a resource request (secondresource request), and transmits the resource request to the IWF-u 32(a9 in FIG. 4).

The switch control unit 321 of the IWF-u 32 acquires the first parameterfrom the received resource request, reserves a user data resource (a10in FIG. 4), and transmits to the IWF-c 31 a notification that theresource has been reserved (all in FIG. 4). This notification containsthe second parameter (e.g., the address of the RNC 1) used to transferuser data by the IWF-u 32.

The resource management unit 311 of the IWF-c 31 acquires the secondparameter from the received notification. The resource management unit311 rewrites, with the address of the IWF-u 32, the address of the MSC 4serving as a user data transfer destination address in “RAB AssignmentRequest”. The resource management unit 311 transfers the rewritten “RABAssignment Request” to a proper control signal transmission/receptionsection in the RNC 1 (a12 in FIG. 4). Selection of a proper controlsignal transmission/reception section utilizes the SCCP correspondencetable.

After that, the RNC 1 reserves a user data resource (a13 in FIG. 4). Inorder to set the U-Plane, the RNC 1 transmits “Establish Request” to theaddress of the IWF-u 32 which is notified by “RAB Assignment Request”(a14 in FIG. 4). This notification contains the user data address of theRNC 1. Transmission of the notification can utilize IPALCAP (IP AccessLink Control Application Protocol).

Upon reception of the notification, the IWF-u 32 transmits “EstablishRequest” to the MSC 4 by ALCAP (Access Link Control ApplicationProtocol) (al5 in FIG. 4). As the destination of the MSC 4, the addressof the MSC 4 that has been notified from the IWF-c 31 in advance isused.

“Establish Confirm” is transmitted as a confirmation message from theMSC 4 to the IWF-u 32 and from the IWF-u 32 to the RNC 1 (a16 and a17 inFIG. 4). Then, a radio resource is reserved between the UE and the RNC 1(al8 in FIG. 4). When a radio resource is reserved, “RAB AssignmentResponse” is transmitted from the RNC 1 to the IWF-u 32 and from theIWF-u 32 to the MSC 4, completing setting of a user data transfer path(al9 and a20 in FIG. 4).

By using the set path, user data is transferred.

The same process is also performed when the resource of the IWF-u 33 isreserved.

FIG. 5 is a sequence chart showing operation up to reservation of theresource of each device upon issuing a PS call according to the firstembodiment. Operation up to reservation of the resource of each deviceupon issuing a PS call according to the first embodiment will beexplained with reference to FIG. 5.

Referring to FIG. 5, operation up to reservation of the resource of eachdevice upon issuing a PS call is almost the same as the above-describedoperation up to reservation of the resource of each device upon issuinga CS call. That is, operations in b1 to b13 in FIG. 5 are the same asthose in a1 to a13 in FIG. 13. However, the PS call does not use eitherALCAP or IPALCAP, and thus the last “RAB Assignment Response” isdifferent from that in FIG. 4.

After a radio resource is reserved between the UE and the RNC 1 (b14 inFIG. 5), the IWF-c 31 completes setting of a user transfer path by “RABAssignment Response” (b15 in FIG. 5). Then, the IWF-c 31 acquires theuser data address of the RNC 1 by “RAB Assignment Response”, andnotifies the IWF-u 32 of the address (b16 in FIG. 5). As the response,the IWF-u 32 notifies the IWF-c 31 of the address of the IWF-u 32 on theside of the MSC 4 (b17 in FIG. 5). The IWF-c 31 acquires the address,and rewrites, with the address of the IWF-u 32, the address of the RNC 1serving as a user data transfer destination address in “RAB AssignmentResponse”. The IWF-c 31 transmits the rewritten “RAB AssignmentResponse” to the MSC 4 (b18 in FIG. 5).

At this time, the SCCP connection utilizes the SCCP correspondencetable. The SCCP is assigned with a line number so as to confirm eachlink. For each link number, the SCCP correspondence table storesinformation representing a correspondence between a link number to theMSC 4 or SGSN 5 and a link number to the RNC 1.

The subsequent process is the same as the above-described process uponissuing a CS call.

The same process is also performed when the resource of the IWF-u 33 isreserved.

A sequence for reserving a resource has been described in detail in theabove operations shown in FIGS. 4 and 5. A resource can also be freed bythe same sequence.

FIGS. 6 and 7 are flowcharts showing operation of the IWF-c 31.Operation of the IWF-c 31 in the IWF device 3 will be explained withreference to FIGS. 6 and 7.

Upon reception of signalling (step S1 in FIG. 6), the IWF-c 31determines whether it has received signalling from the RNC 1 or MSC 4(step S2 in FIG. 6).

For RANAP signalling received from the RNC 1, the IWF-c 31 notifies theIWF-us 32 and 33 of an RNC address (step S15 in FIG. 7) for only “RABAssignment Response” representing a resource reservation response to aPS call (step S14 in FIG. 7).

The IWF-c 31 waits for responses from the IWF-us 32 and 33, and acquiresan IWF-u (RNC 1 side) address (step S16 in FIG. 7). The IWF-c 31rewrites the RNC address for user data in signalling with the addressesof the IWF-us 32 and 33 (step S17 in FIG. 7), and transmits RANAPsignalling to the MSC 4 (step S18 in FIG. 7); otherwise, the IWF-c 31directly transmits RANAP signalling to the MSC 4 (step S18 in FIG. 7).

Upon reception of the RANAP signalling from the MSC 4 (step S3 in FIG.6), if no SCCP correspondence table for the number of a control signaltransmission/reception section and an SCCP connection has been createdupon first RANAP signalling (e.g., Paging) from the MSC 4 (step S4 inFIG. 6), the IWF-c 31 arbitrarily selects a control signaltransmission/reception section, and directly transmits RANAP signallingto the control signal transmission/reception section (steps S11 to S13in FIG. 6).

If no correspondence between an SCCP connection and the number of acontrol signal transmission/reception section has been created, an SCCPcorrespondence table is created (step S12 in FIG. 6). The SCCPcorrespondence table is deleted at the same time as the end of a call(end of the SCCP connection).

The IWF-c 31 determines whether the RANAP signalling is “RAB AssignmentRequest” to reserve a user data resource (step S6 in FIG. 6). If theRANAP signalling is a request to reserve a user data resource, the IWF-c31 exchanges signalling with the IWF-us 32 and 33, and reserves theresources of the IWF-us 32 and 33. Thereafter, the IWF-c 31 rewrites,with the addresses of the IWF-us 32 and 33, the address of the MSC 4serving as the user data transfer destination of RANAP signalling (stepsS7 to S9 in FIG. 6), acquires the destination of a control signaltransmission/reception section from the SCCP correspondence table, andtransmits signalling to the control signal transmission/receptionsection (step S10 in FIG. 6).

If the request does not reserve a user data resource, the IWF-c 31transmits RANAP signalling to a proper control signaltransmission/reception section without changing RANAP (step S10 in FIG.6).

FIGS. 8 and 9 are flowcharts showing operation of the IWF-us 32 and 33in FIG. 1. Operation of the IWF-us 32 and 33 will be explained withreference to FIGS. 8 and 9.

Upon reception of resource reservation signalling from the IWF-c 31(step S23 in FIG. 8 and step S28 in FIG. 9), the IWF-us 32 and 33reserve their internal resources (step S29 in FIG. 9). The IWF-us 32 and33 store, in correspondence with their IWF-u addresses, the address ofthe MSC 4 which has been notified by signalling, and notify the IWF-c 31of the IWF-u addresses (step S30 in FIG. 9).

Upon reception of signalling from the RNC 1 (step S24 in FIG. 8), theIWF-us 32 and 33 migrate the IPALCAP signalling to ALCAP, and transmitthe signalling to a corresponding MSC address (step S27 in FIG. 8).

Upon reception of signalling from the MSC 4 (step S25 in FIG. 8), theIWF-us 32 and 33 migrate the ALCAP signalling to IPALCAP, and transmitthe signalling to a corresponding RNC address (step S26 in FIG. 8).

As described above, the IWF-us 32 and 33 convert a protocol by the sameuser data flow as that for receiving signalling from the RNC 1 or MSC 4.

In this manner, according to the first method, the IWF device 3 isdivided into the C-Plane device (IWF-c 31) and the U-Plane device(IWF-us 32 and 33), and the IWF device 3 can employ a configuration withhigh scalability. More specifically, the IWF-c 31 is not influenced byincreasing/decreasing the number of IWF-us 32 and 33.

In the first embodiment, since the IWF device 3 terminates SCCP everycall, a plurality of control signal transmission/reception sections 11to 13 can be installed in the RNC 1. Conventionally, only one controlsignal transmission/reception section is used as the RNC 1.

In the first embodiment, when the IWF device 3 is divided into theC-Plane device (IWF-c 31) and the U-Plane device (IWF-us 32 and 33), aresource is reserved in the U-Plane device (IWF-us 32 and 33) inresponse to a request from the C-Plane device (IWF-c 31), distributingthe load of the IP traffic using the shortest path.

SECOND EMBODIMENT

FIG. 10 is a block diagram showing the configuration of an IWF device asa protocol conversion device according to the second embodiment of thepresent invention. The second embodiment is different from theabove-described first embodiment in that in FIG. 10, no signal istransmitted/received between an IWF-c 31 and IWF-us 71 and 72 in an IWFdevice 7, and the IWF-us 71 and 72 are controlled by control signaltransmission/reception sections 61 to 63 of an RNC 6. The same referencenumerals as those in the first embodiment denote the same parts.

In the first embodiment, the IWF-c 31 needs to recognize RANAPsignalling, and thus must decode all signallings to recognize whether“RAB Assignment Request” exists. To the contrary, in the secondembodiment, the resources of the IWF-us 71 and 72 are managed by thecontrol signal transmission/reception sections 61 to 63 in the RNC 6.Hence, the IWF-c 31 need not decode RANAP signalling, reducing theprocess of the IWF-c 31.

FIG. 11 is a block diagram showing the configurations of the IWF-c 31and IWF-u 71 in FIG. 10. In FIG. 11, the IWF-c 31 is formed fromprotocol termination units 312 and 314, and a signal transfer unit 315.The IWF-u 71 is formed from a resource management unit 711, a switch322, protocol termination units 324 to 326 on the ATM side, and protocoltermination units 327 to 329 and 712 on the IP (Internet Protocol) side.

FIG. 12 is a view showing the protocol stack of the C-Plane according tothe second embodiment. The second embodiment is different from theabove-described first embodiment in that the SCCP layer and RANAP layerin the protocol stack are not terminated by the IWF-c 31. The remainingpart is the same as that in the first embodiment.

FIG. 13 is a sequence chart showing operation upon issuing a CS callaccording to the second embodiment. Operation up to reservation of theresource of each device upon issuing a CS call according to the secondembodiment will be explained with reference to FIG. 13.

In FIG. 13, according to the second embodiment, an SCCP connection isterminated between the RNC 6 and the MSC 4, and the IWF-c 31 does notconcern the termination. Since a flag for identifying a control signaltransmission/reception section used by the RNC 6 is attached in the SCCPconnection, the IWF-c 31 can determine the flag to select a propercontrol signal transmission/reception section.

“RAB Assignment Request” (fourth resource request) transmitted from theMSC 4 reaches the RNC 6 without being concerned by the IWF-c 31 (c6 inFIG. 13). Upon reception of “RAB Assignment Request”, the RNC 6 reservesa user data resource (c7 in FIG. 13). The RNC 6 which has reserved theresource transmits to the IWF-u 71 a resource request (third resourcerequest) to reserve the resource of the IWF-u 71 (c8 in FIG. 13). Byadding the address of the RNC 6 to the address of an MSC 4 in theresource request, the resource request replaces “Establish Request” ofIPALCAP.

The IWF-u 71 acquires the address of the MSC 4 serving as a user datatransfer destination, and reserves a user data resource (c9 in FIG. 13).The IWF-u 71 transmits “Establish Request” to the MSC 4 by ALCAP (c10 inFIG. 13). The IWF-u 71 waits for “Establish Confirm” which is sent backto the IWF-u 71 by ALCAP in response to the request (c11 in FIG. 13).Then, the IWF-u 71 notifies the RNC 6 of the address of the IWF-u 71(c12 in FIG. 13).

The subsequent process is the same as that in the first embodiment.

The same process is also executed when the resource of the IWF-u 72 isreserved.

FIG. 14 is a sequence chart showing operation upon a PS call accordingto the second embodiment. Operation up to reservation of the resource ofeach device upon issuing a PS call according to the second embodimentwill be explained with reference to FIG. 14.

Since the PS call does not use “Establish Request” by ALCAP, nooperation need be changed between the CS call and the PS call in “RABAssignment Response” (dl2 in FIG. 14).

In the second embodiment, the IWF-c 31 need not reserve any resource,and the control signal transmission/reception sections 61 to 63 in theRNC 6 reserve resources. The IWF-c 31 can omit the determination stepshown in FIGS. 6 and 7, and performs only protocol conversion of a lowerlayer.

FIG. 15 is a flowchart showing operation of the IWF-u 71 in FIG. 10. InFIG. 15, processes in steps S41 to S48 are the same as those shown inFIGS. 8 and 9. Since the decision processes in steps S23 and S28 areomitted and the number of decision processes decrease, the process bythe IWF-u 71 can be reduced.

As described above, according to the second embodiment, since thecontrol signal transmission/reception sections 61 to 63 in the RNC 6control signalling for reserving the resources of the IWF-us 71 and 72,the IWF-c 31 need not decode RANAP signalling and need not terminate anySCCP connection. Since the IWF-c 31 and the IWF-us 71 and 72 becomeirrelevant to each other, flexibility can also be ensured forimplementation, and the IWF-us 71 and 72 can be easily implemented inthe RNC 6.

As has been described above, the IWF device 3 or 7 according to theabove embodiments is divided into a C-Plane device for controllingsignalling and a U-Plane device for controlling user data, and thus canadopt a configuration with high scalability. The RNC 1 or 6 can alsoadopt a configuration with high scalability. Note that the IWF device 3or 7 can be applied not only when it is connected between differentphysical lines but also when different intermediate protocols are usedfor the same physical line.

1. (canceled)
 2. A protocol conversion device which is connected betweena first device and a second device that use different physical lines,characterized by comprising: a C Plane device which controls signallingbetween the first device and the second device; and a U Plane devicewhich controls transfer of user data between the first device and thesecond device said C Plane device comprising a resource management unitwhich transmits a second resource request to said U Plane device when afirst resource request to reserve a user data resource is received fromthe first device, and said U Plane device comprising a control unitwhich reserves the user data resource in said U Plane device when thesecond resource request is received.
 3. A protocol conversion deviceaccording to claim 2, characterized in that the resource management unitacquires a first parameter which is contained in the first resourcerequest and used to transfer the user data in the first device, and addsthe parameter to the second resource request.
 4. A protocol conversiondevice according to claim 3, characterized in that the control unittransmits to said C Plane device a resource reservation notification towhich a second parameter for transferring the user data in said U Planedevice is added after a resource is reserved, and the resourcemanagement unit acquires the second parameter from the received resourcereservation notification, and transfers to the second device a firstresource request obtained by rewriting the first parameter contained inthe first resource request with the second parameter.
 5. A protocolconversion device which is connected between a first device and a seconddevice that use different physical lines, characterized by comprising: aC Plane device which controls signalling between the first device andthe second device; and a U Plane device which controls transfer of userdata between the first device and the second device, said U Plane devicecomprising a resource management unit which reserves a user dataresource in said U Plane device when a third resource request to reservethe user data resource is received from the second device.
 6. A protocolconversion device according to claim 5, characterized in that theresource management unit acquires parameters which are contained in thethird resource request and used to transfer the user data in the firstdevice and the second device.
 7. A protocol conversion device accordingto claim 5, characterized in that the second device transmits the thirdresource request to said U Plane device when a fourth resource requestto reserve the user data resource is received from the first device. 8.A protocol conversion device which is connected between a first deviceand a second device that use different physical lines, characterized bycomprising: a C Plane device which controls signalling between the firstdevice and the second device; and a U Plane device which controlstransfer of user data between the first device and the second device,wherein the first device is at least one of an MSC (Mobile SwitchingCenter) and an SGSN [Serving GPRS (General Packet Radio Service) SupportNode] using an ATM (Asynchronous Transfer Mode) transport protocolstack, and the second device is a base station control device using anIP (Internet Protocol) transport protocol stack.
 9. A protocolconversion device according to claim 8, characterized in that SCCP(Signalling Connection Control Part) connections are set between said CPlane device and said at least one of the MSC and the SGSN and betweensaid C Plane device and the base station control device.
 10. A protocolconversion device according to claim 9, characterized in that the basestation control device comprises a plurality of signalling controldevices for transmitting/receiving a control signal, and said C Planedevice stores an SCCP correspondence table which makes a number of eachsignalling control device and an SCCP connection correspond to eachother, and when signalling is received from said at least one of the MSCand the SGSN, selects one of the signalling control devices on the basisof the SCCP correspondence table.
 11. (canceled)
 12. A protocolconversion method applied when a first device and a second device thatuse different physical lines are connected, characterized by comprising:the first step of controlling signalling between the first device andthe second device by a C Plane device; and the second step ofcontrolling transfer of user data between the first device and thesecond device by a U Plane device which is arranged independently of theC Plane device the first step comprising the third step of transmittinga first resource request to reserve a user data resource from the firstdevice to the C Plane device, the fourth step of transmitting a secondresource request to the U Plane device when the C Plane device receivesthe first resource request, and the fifth step of reserving the userdata resource in the U Plane device when the U Plane device receives thesecond resource request.
 13. A protocol conversion method according toclaim 12, characterized in that the fourth step comprises the step ofacquiring a first parameter which is contained in the first resourcerequest and used to transfer the user data in the first device, andadding the parameter to the second resource request.
 14. A protocolconversion method according to claim 13, characterized in that the firststep comprises the sixth step of transmitting to the C Plane device aresource reservation notification to which a second parameter fortransferring the user data in the U Plane device is added after thefifth step, and the seventh step of acquiring the second parameter fromthe received resource reservation notification, and transferring to thesecond device a first resource request obtained by rewriting the firstparameter contained in the first resource request with the secondparameter.
 15. A protocol conversion method applied when a first deviceand a second device that use different physical lines are connected,characterized by comprising: the first step of controlling signallingbetween the first device and the second device by a C Plane device; andthe second step of controlling transfer of user data between the firstdevice and the second device by a U Plane device which is arrangedindependently of the C Plane device, the first step comprising theeighth step of transmitting a third resource request to reserve a userdata resource from the second device to the U Plane device, and theninth step of reserving the user data resource in the U Plane devicewhen the U Plane device receives the third resource request.
 16. Aprotocol conversion method according to claim 15, characterized in thatthe ninth step comprises the step of acquiring parameters which arecontained in the third resource request and used to transfer the userdata in the first device and the second device.
 17. A protocolconversion method according to claim 15, characterized in that the firststep further comprises the 10th step of transmitting a fourth resourcerequest to reserve the user data resource from the first device to thesecond device before the eighth step, and the eighth step comprises thestep of transmitting the third resource request to the U Plane devicewhen the second device receives the fourth resource request.
 18. Aprotocol conversion method applied when a first device and a seconddevice that use different physical lines are connected, characterized bycomprising: the first step of controlling signalling between the firstdevice and the second device by a C Plane device; and the second step ofcontrolling transfer of user data between the first device and thesecond device by a U Plane device which is arranged independently of theC Plane device, wherein the first device is at least one of an MSC(Mobile Switching Center) and an SGSN [Serving GPRS (General PacketRadio Service) Support Node] using an ATM (Asynchronous Transfer Mode)transport protocol stack, and the second device is a base stationcontrol device using an IP (Internet Protocol) transport protocol stack.19. A protocol conversion method according to claim 18, characterized inthat the first step comprises the 11th step of setting SCCP (SignallingConnection Control Part) connections between the C Plane device and saidat least one of the MSC and the SGSN and between the C Plane device andthe base station control device.
 20. A protocol conversion methodaccording to claim 19, characterized in that the first step furthercomprises the 12th step of, when signalling is received from said atleast one of the MSC and the SGSN, selecting one of a plurality ofsignalling control devices on the basis of an SCCP correspondence tablewhich makes a number of each of the signalling control devices of thebase station control device and an SCCP connection correspond to eachother.